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METHOD AND SYSTEM FOR SUPERVISING ON-LINE PURCHASING 

Field of the Invention 

This invention relates to methods and systems for conducting on-line purchases, 

5 

Background of the Invention 

Electronic commerce has been growing at a rapid pace, and provides 
opportunities for companies to sell products to customers who are not physically present 
at a company's store. For many individuals, electronic commerce provides convenience 

IQ and an ability to obtain better prices. However, the electronic commerce opportunities 
are considerably more Umited for individuals who do not have credit cards or who need 
to obtain the approval of someone with purchasing authority before completing a 
purchase. These limitations are particularly evident in the case of minors, who typically 
do not have credit cards or any other mechanism for purchasing items electronically. 

J 5 These limitations also are evident in various group or team buying situations, in both 
corporate and family settings. 

Recently, a number of systems have been announced to attempt to meet the needs 
of minors. These systems include those described at www.allowancenet.com, 
www.cybermoola.com, www.doughboy.com, www.echarge.com, www.icanbuy.com, 

20 www.pocketcard.com, and www.rocketcard.com. These systems employ various models, 
but appear to provide limited flexibility and options. For example, these systems are 
limited in the variety and combination of purchasing approvals, purchasing restrictions, 
and payment options that are available to the parents or others with purchasing authority 
over children or others. These systems also are limited in how they use information 

25 about prior purchases and prior attempts to make purchases. 

Another limitation with existing electronic conunerce systems is the lack of 
consumer-oriented purchase management systems that allow purchase selections to be 
managed and reviewed prior to the final purchase transaction. 



30 
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Summary of the Invention 

According to the present invention, a supervisor, parent, or other individual, 
group of individuals, or entity with spending approval authority over others (an 
"authorized) establishes a master account and one or more subordinate accounts with an 
approval system. Each subordinate account typically corresponds to a family member or 
a member of a buying team (such as the members of a purchasing department) but could 
correspond to any individual or entity for which the authorizer has spending approval 
authority. An individual or entity for which an authorizer has such approval authority is 
identified generally herein as a subordinate. The combination of the master account and 
associated subordinate accounts is identified herein as a family of accounts. 

Through the master account, the authorizer can individually determine how each 
subordinate will be permitted to make electronic purchases and what limitations will be 
imposed on the purchases a subordinate may make. For example, a subordinate account 
may be set up so that the authorizer must approve each purchase before it can be 
completed. Or, purchases can be pre-approved, provided they meet certain criteria, such 
as criteria based on the type of item, the cost of the item, or the vendor. Criteria may be 
inclusive (only those items meeting the criteria may be purchased) or exclusive (items 
meeting the criteria may not be purchased). Where purchases are pre-approved, a credit 
card, a bank account, or any other spending mechanism may be used. Like the approval 
criteria, the spending mechanism may be specified for each subordinate or for a type of 
transaction. The master account also permits the coordination of group purchases. 

Spending criteria and the approval mechanism can be separate. For example, 
even purchases meeting the criteria can require express approval by the authorizer. 

The authorizer also can configure the extent to which each subordinate receives 
notifications of items that are approved or rejected, and the extent to which each 
subordinate has access to personal catalog functions. 

Once the criteria and approval process are established, a subordinate may 
purchase any item matching the criteria (and subject to the approval process) that is 
available over a network or collection of networks, such as the World Wide Web. As 
long as the vendor recognizes the approval system, the transaction may be conducted. 
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The approval system, in addition to being used to determine whether a purchase 
takes place, can provide feedback to the subordinate. For example, the approval system 
can explain the criteria to a subordinate who attempts to make purchases that do not meet 
the criteria, or can assist the subordinate in revising an order so as to meet the criteria. 

Optionally, the approval system maintains a database with information about the 
prior items examined and selected by each subordinate within a family of accounts, and 
(where appropriate) whether each item has been approved or not. This permits the 
creation of a personal catalog, based on items previously viewed or approved by a 
particular subordinate and/or by others within a family of accounts. 

Brief Description of the Drawings 

Figure 1 is a block diagram of a computer network for use with an embodiment of 
the present invention. 

Figure 2 is a representation of a structure for a family of accounts according to an 
embodiment of the present invention. 

Figure 3 is a flow diagram of steps performed according to an embodiment of the 
present invention. 

Figure 4 is a flow diagram of steps performed according to an embodiment of the 
present invention. 

Figure 5 is a representation of a structure for implementing a system according to 
an embodiment of the present invention. 

Figure 6 is a flow diagram of steps performed according to an embodiment of the 
present invention. 

Figure 7 is a representation of a structure for implementing a system according to 
an embodiment of the present invention. 

Figure 8 is a representation of a structure for implementing a system according to 
an embodiment of the present invention. 

Figure 9 is a flow diagram of steps performed according to an embodiment of the 
present invention. 

Figures 10a and 10b are representations of structures for implementing a system 
according to an embodiment of the present invention. 
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Detailed Description of Preferred Embodiments 

Referring to Figure 1, networked system 10 includes user sites 20, approval 
system 30, and vendor presentations 40, all connected to network 50. In a preferred 

5 embodiment, network 50 is the World Wide Web; however, any other network, including 
a private or dedicated network could be used. User sites 20 include a personal computer 
configured to interact over network 50. For example, a user site 20 may include a 
multimedia-capable, Pentium IBM-PC compatible personal computer 22 running 
Microsoft Windows 95, 98, or NT, with a modem for connecting to the Internet, 

jQ Personal computer 22 also runs an Internet browser, such as Microsoft Internet Explorer 
or the Netscape Navigator. 

Approval system 30 includes server 32 and database server 34 running an Oracle 
or other database system 36. Depending on the size of approval system 30, server 32 and 
database server 34 could be a single physical server or multiple servers, as appropriate to 

J 5 meet the expected system needs. 

Vendor presentations 40 may consist of an online store in which products or 
services are presented for purchase. Such online stores may include a web server 42, an 
HTTP server 44, and databases 46. A vendor presentation also could consist of a product 
offer within the context of an online advertisement. Such an online advertisement 

20 typically consists of a specific offer for a specific product or service within the context of 
an advertisement placed in a high-traffic web site. The advertisement may consist of 
HTML-based content running on an HTTP server. With an advertisement, a purchase 
may be initiated by interacting with the advertisement. 

As shown in Figures 2 and 3, in order to set up a family of accounts, an authorizer 

25 at a user site 20 accesses approval system 30 over network 50 (step 210). At step 215, 
the authorizer provides identifying information 112, such as name, address, and 
electronic mail address, for a master account 100, and lists each subordinate for which a 
subordinate account 102 is to be created. Approval system 30 assigns to master account 
100 an account ID 104 and password 106, at step 220, to permit items to be approved and 

30 parameters to be set or changed, as described below. Similarly, at step 225, authorizer 
provides identifying information 1 14 for each subordinate account 102, and approval 
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system 30 assigns an account ID 108 and a password 1 10 for each subordinate account 
102. Optionally, the authorizer and each subordinate may be permitted to change the 
assigned password. Approval system 30 stores this account information in database 
system 36. If desired, the master account can have multiple account ID's (and 
corresponding passwords), so that multiple individuals can serve as authorizers. An 
authorizer subsequently can add or remove subordinates. 

Optionally, at step 230, after establishing each account, the authorizer establishes 
a default set of parameters 120, which apply to each subordinate account unless 
overridden for that account. Parameters 120 are stored in database system 36, In a 
preferred embodiment, parameters 120 include payment information 122, pre-approval 
status 124, and purchase criteria 126. Approval system 30 can have one or more standard 
sets of criteria, which can be selected as is or modified, to simplify the establishment of 
the accounts. 

Preferably, payment information 122 includes one or more of the following: credit 
card information 130 for one or more credit cards, credit card proxies 132 for one or 
more virtual accounts, and account information 134 for one or more bank accounts 
(which can be either traditional or on-line banks). Any other payment mechanism, 
whether prepaid or credit-based, can also be provided. Where all transactions will 
require the approval of the authorizer, payment information 122 can be omitted, and 
provided for individual transactions. 

Pre-approval status 124 identifies whether the authorizer must approve an 
individual transaction or whether an individual transaction is pre-approved, subject to 
meeting the purchase criteria 126. Optionally, multiple levels of approval can be 
estabUshed, so that certain types of purchases (those meeting specified criteria) are pre- 
approved, others (meeting other specified criteria or not meeting the criteria for pre- 
approval) require individual approval, and others are automatically rejected. 
Alternatively, all purchases meeting the specified criteria can be subject to individual 
approval. 

Purchase criteria 126 can be used to determine whether an item is in a pre- 
approved category, whether it falls within a category of items that must be individually 
approved, or whether it falls within a category of items that automatically are rejected. 
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Generally, items that automatically are rejected with be items that do not meet the 
purchase criteria either for pre-approval or to permit individual approval. If the purchase 
criteria determine only whether an item is pre-approved, items not meeting the purchase 
criteria may be items that require individual approval or may be items that automatically 
are rejected. If no items are pre-approved, items meeting the purchase criteria will 
require individual approval and items not meeting the purchase criteria automatically will 
be rejected. 

The criteria 126 can be inclusive criteria 140 or exclusive criteria 142. Inclusive 
criteria describe characteristics of items that may be purchased, and exclusive criteria 
describe characteristics of items that may not be purchased. Inclusive criteria 140 and 
exclusive criteria 142 can be combined for each category. Criteria 126 are combined in a 
Boolean fashion to determine the category in which an item falls. 

The criteria 126 include absolute criteria, such as the price of an item, the type of 
item (such as video game, book, clothing, or the rating of a video), the vendor, the day or 
time, and specified words in the title or description of the item. These criteria can be 
combined, so that the price cutoff for an item depends on the type of item or the vendor. 
Criteria 126 also include relative criteria. Relative criteria can include, for example, the 
total amount selected by the subordinate from the vendor in this transaction, the total 
amount selected from the vendor within a given time period (such as the past 30 days), 
the total amount selected from all vendors within a given time period, and the total 
amount for items of a certain type or group of types (such as the combined amount spent 
on video games and music in the current month). 

Criteria need not be subordinate-specific. They can be cumulative for some or all 
of the subordinates. For example, in a business purchasing context, the criteria may be 
cumulative to ensure that two team members do not purchase the same item. The criteria 
also can include specific items purchased by other subordinates within the applicable 
time period. For example, the criteria can limit all subordinates to a maximum of ten of 
the same items (whatever they may be) from an office supplies category. 

After establishing the default parameters (if desired), the authorizer establishes, at 
step 235, the parameters for each subordinate account. If default parameters have been 
established, then this step may be omitted for any subordinate whose parameters are the 
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same as the default parameters. Similarly, if default parameters have been established, 
then only those parameters that differ from the defaults need to be established. 

The criteria can be established in many different ways. For example, the criteria 
can be established in the following manner for a subordinate account. First, as shown at 
step 805 in Figure 9, the authorizer selects the subordinate account of interest. Next, at 
step 810, the authorizer enters a total budget amount and the time period covered by the 
budget amount (such as a month). The authorizer then indicates (step 815) whether 
purchases meeting certain criteria will be pre-approved. If so, the authorizer selects from 
previously entered financial accounts or enters a new account for making payments on 
this subordinate's account (step 820). Next, the authorizer identifies (step 825) a first 
budget segment. For example, a budget segment might be "school supplies." The 
authorizer then enters a percentage or amount of the budget for this category (step 830). 
If the budget does not include categories or if certain criteria apply to all segments, the 
budget segment identifier is "all" and the percentage is 100 percent. The segment budget 
amount represents the amount of the total budget that is available for the segment. 
Although it cannot be greater than the total budget, the combined totals for the budget 
segments can exceed the total budget amount. For example, a subordinate may be 
permitted to spend up to 60% of the budget on school suppliers and up to 50% of the 
budget on clothes, but cannot exceed the total budget in doing so. After selecting a 
percentage or amount of the budget for the segment, the authorizer (step 835) enters an 
approval category (pre-approved, requires individual approval, automatically rejected). 
The authorizer also enters the criteria (step 840) that apply for that category. These could 
include, for example, approved (or disapproved) vendors for the segment, maximum cost 
of any one item, the days or times during which an item can be purchased, and 
description information about the items. The authorizer then has the option (step 845) to 
select another approval category for that budget segment. If so, the authorizer enters the 
new approval category (from step 835) and continues as before. When the authorizer has 
specified all of the approval categories for that budget segment, the authorizer has the 
option to enter a new budget segment (step 850), in which case the authorizer repeats the 
steps beginning with step 825. After the authorizer has specified all budget segments, 
approval system 30 saves the budget segments (step 855) to database system 36. The 
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authorizer then has the option (step 860) to enter criteria for another subordinate or to end 
this process. The authorizer later can edit any portions of the criteria. 

As shown in Figure 4, a subordinate desiring to purchase an item uses the World 
Wide Web to find one or more items of interest (step 305) from a vendor presentation 40. 

5 The vendor presentation may be, for example, a vendor's online store, a vendor 

advertisement, or any other web site that provides access to the vendor's items. At step 
310, the vendor (which could be, for example, the online store, or another web site or an 
agent able to provide the item) sends a request to approval system 30 for payment. To 
accomplish this, the subordinate provides an identification of the subordinate's account 

IQ with the approval system to the vendor. The necessary information regarding the order is 
sent from vendor site 40 to approval system 30, preferably using an Extensible Markup 
Language (XML) gateway. The XML data is sent using Hypertext Transfer Protocol 
(HTTP), using for example the Secure Socket Layer (SSL) for security. Alternatively, an 
electronic mail message or other communications channels could be used to send the 

j5 order information from vendor presentation 40 to approval system 30. 

Upon receiving the request for payment, approval system 30 accesses database 
system 36 to compare (step 315) the items to the criteria established for that subordinate 
and determine the category for each item. Optionally, approval system 30 forwards this 
information to the subordinate by electronic mail or posts this information (at a site 

20 accessible only using the subordinate's password) so that the subordinate can learn the 
status of each item (step 320). In addition, approval system can explain the purchase 
criteria to the subordinate or assist the subordinate in revising an order so as to meet the 
criteria, as explained below. 

Items meeting the purchase criteria then are further processed in accordance with 

25 whether the purchase is pre-approved. For each item (if any) that is pre-approved, 
approval system 30 determines the appropriate payment information 122 (step 330), 
previously entered by the authorizer, then sends the order along with the appropriate 
payment information 122 to the vendor (step 335). In addition, each of these items is 
added to database system 36 (step 340). 

30 Approval system 30 adds each item (if any) for which individual approval is 

required to a daily list 150 (Figure 5) for that subordinate (step 350). Preferably, daily 
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list 150 includes entries 152 with the name of the item, its price, the vendor, any available 
description of the item, and a link 154 to the web page for that item. Alternatively, a 
single daily list 150 can be used for all subordinates, in which case daily list 150 also 
includes the name of the subordinate in each entry 152. 

At the beginning of each day (or other time period), Ust 150 is empty (step 510 in 
Figure 6). During the day, approval system 30 may add items to list 150 as a result of the 
subordinate seeking to purchase items (step 515). Also, the subordinate may access the 
list and delete items (step 520). At the end of the day (or other time period), approval 
system 30 sends all items on list 150 to an electronic mail address for the master account 
(step 525). The authorizer then determines which items to approve, designates a payment 
mechanism (which can be a default mechanism), and returns that information to approval 
system 30 (step 530), using a web-based form, return electronic mail, or any other desired 
mechanism. The authorizer approves or rejects an item by clicking on the appropriate 
selection within approval field 156. Optionally, the authorizer provides reasons when 
rejecting an item. For each item that is approved, approval system 30 sends the order 
along with the appropriate payment information 122 to the corresponding vendor (step 
535). Each item, whether accepted or rejected, is added to database system 36 (step 540). 
As with the initial list of categories into which each item falls, approval system 30 in a 
preferred embodiment informs the subordinate of the items that have been approved and 
rejected (step 545). Alternatively, where appropriate, the subordinate is not informed. 
Finally (step 550), approval system 30 empties list 150. 

The authorizer need not approve or reject all items at one time. For example, the 
authorizer could approve two items from the list and reject a third item, exit from the 
approval system's web site, then return later to approve or reject the remaining items. 
Once items have been approved or rejected in one session, that status is shown in 
subsequent sessions. 

As with items that are pre-approved or that required individual approval, items 
that were automatically rejected are added to database system 36 (step 360 in Figure 4) as 
items that were requested but rejected. 

As shown in Figure 7, items are maintained in database system 36 according to 
the subordinate, the item name or other identifier (including, where possible, a URL for 
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the web page showing the item), the date the subordinate requested the item, the item's 
price, the vendor of the item (including a URL for the vendor), the type of item, whether 
the item was approved or rejected, and the basis for rejecting the item (if applicable). For 
example, an item might have been rejected because of its cost, because of the other items 
requested, or because the authorizer rejected it. This information permits the system to 
keep track of each subordinate's purchase history, which may be used by the authorizer 
to review the purchase history, and also for determining the approval of subsequent items 
(as described above) or for establishing a personal catalog. Optionally, database system 
36 includes for each item a field indicating the approval category (e.g., pre-approved, 
requires individual approval, automatically rejected) into which the item fell and a list of 
the criteria applied in making the categorization. Where the authorizer provides reasons 
for rejecting an item, those reasons also may be included in database system 36. 

Each subordinate has a personal catalog 160, as shown in Figure 8, which shows 
each item from database system 36 that the subordinate previously selected. Optionally, 
only items requested within a set time period (such as the past three months) are shown, 
unless the subordinate requests a different time period. In addition, personal catalog 160 
may be purged periodically of old entries. 

Each entry 162 in personal catalog 160 includes the name of the item 170, the 
date the subordinate requested the item 172, the price of the item 174, the vendor for the 
item 176, the type of item 178, whether the item was approved or rejected 180, and the 
basis (if applicable) for rejection of the item 182. Alternatively, the basis for rejection 
182 or other information can be omitted from personal catalog 160 either automatically 
or if specified by the authorizer. 

The subordinate is able to view the personal catalog by pointing a web browser to 
the web site of approval system 30 and entering the subordinate's account ID and 
password. While viewing the personal catalog, the subordinate can click on a vendor 
176, which provides a link to the vendor's web site. Similarly, the subordinate can click 
on an item 174, which provides a link to the location at the vendor's web site where the 
item is displayed. This provides a simple mechanism for repeat ordering. By clicking on 
the basis for rejection 182, the subordinate is able to determine whether the subordinate 
might now be able to purchase the item because conditions have changed. 
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Preferably, personal catalog 160 also provides a Unk 188 to the purchase criteria 
126 applicable to that subordinate. This permits the subordinate to understand the 
authorization criteria. However, where appropriate, access to this information can be 
omitted or limited. 

In a preferred embodiment, personal catalog 160 also includes a link 190 to 
information from the personal catalogs of other subordinates within the family of 
accounts. As appropriate, the authorizer can limit the fields from each entry for a 
subordinate that are visible to other subordinates. Also, each subordinate may be 
provided the ability to designate certain fields as private (by, for example, clicking on the 
identifier for the field), subject to override by the authorizer. A private field is not visible 
to other subordinates. Where information from other personal catalogs is available to a 
subordinate, the subordinate can click on entries to view the vendor, item, or other 
information, as with the subordinate's own personal catalog. 

Personal catalog also includes table 192 showing the applicable total budget and 
budget segments, the total amount spent and remaining that period, and the amount spent 
and remaining for each budget segment. 

The information that approval system 30 sends a subordinate as to the categories 
into which items have been placed (step 320 in Figure 4) is illustrated in Figure 10a. 
Preferably, information 910 includes entries with the names of the items 912, the date the 
subordinate requested the items 914, the prices of the items 916, the vendors 918, and the 
types of the items 920. In addition, if an item or combination of items fails to meet any 
criteria for pre-approval, approval system 30 provides a description 922 of those criteria. 
For example, if the subordinate attempted to purchase an item for $200 but the maximum 
amount for any one item is $100, description 922 would show the maximum amount, but 
not other criteria (such as permissible vendors) that were not violated. Or, if the 
subordinate attempted to purchase two items, each costing $75, from a category in which 
the total budget was $100, description 922 would show the budget category and amount. 
Approval system 30 also provides a link 924 to the applicable purchase criteria 126. 
Alternatively, all criteria are displayed, with those criteria that were violated shown in a 
different manner. 
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If the subordinate clicks on adjust order button 926, approval system 30 provides 
a table 930 (shown in Figure 10b) that permits the subordinate to try variations on the 
order, to see how that would affect the results. The top half of table 930 includes 
financial status 932, which shows the applicable total budget and budget segments, the 
total amount spent and remaining that period, and the amount spent and remaining for 
each budget segment. The bottom half of table 930 includes the information from Figure 
10a (the names of the items, the date the items were requested, the prices, the vendors, 
the types of the items, a list of the criteria that were not met, and a link to the applicable 
purchase criteria). Unlike the information from Figure 10a, the subordinate can change 
these entries to try different options. For example, the subordinate can delete an item and 
see how that would affect the results. Table 930 includes a "restore" button 934 that 
permits the subordinate to return to the original selections and try again. 

While there have been shown and described examples of the present invention, it 
will be readily apparent to those skilled in the art that various changes and modifications 
may be made therein without departing from the scope of the invention as defined by the 
appended claims. For example, information from the personal accounts of other 
subordinates in a family of accounts could be shown along with the information from a 
subordinate's own personal account, with appropriate designations to indicate whose 
account it is. 

Also, the invention can be applied in different contexts. For example, the system 
can be used as a form of gift registry. After the authorizer establishes criteria, a 
subordinate can choose the specific items that the subordinate desires to receive as gifts. 
All items would be subject to individual approval. The authorizer (or authorizers), by 
"approving" an item, would be purchasing one of the items for the subordinate. In this 
context, the subordinate generally would not receive a notification when the authorizer 
approves or rejects an item. Different authorizers could approve different items off the 
registry, to buy different items for the subordinate. 

Accordingly, the invention is Umited only by the following claims and equivalents 

thereto. 

What is claimed is: 
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Claims 

1 . A method for conducting transactions over a network comprising the steps 

of: 

receiving from one or more vendors a set of items requested by a first user for 
purchase over a network; 

evaluating each item in the set of requested items against one or more purchase 

criteria; 

for each item in the set of requested items that meets the purchase criteria: 

if the purchase of the item also is pre-approved, sending to the vendor of 
the item information permitting the purchase of the item; 

if the purchase of the item is not pre-approved: 

sending to a second user a request for approval of the item; 
receiving from the second user a response to the request for 

approval of the item; and 

if the response includes an approval of the item, sending to the 
vendor of the item information permitting the purchase of the item, and if the response 
includes a rejection of the item, providing to the first user a notice that the item was not 
approved; and 

for each item in the set of requested items that does not meet the purchase criteria, 
providing to the first user a notice that the item does not meet the purchase criteria. 

2. The method of claim 1, further comprising the step of establishing the 
purchase criteria with a plurality of sets of purchase criteria, each of the sets of purchase 
criteria being applicable to a different category of items. 

3. A method for conducting transactions over a network comprising the steps 

of: 

receiving from one or more vendors a set of items requested by a first user for 
purchase over a network; 

evaluating each item in the set of requested items against one or more purchase 

criteria; and 
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for each item in the set of requested items that does not meet the purchase criteria: 
providing to the first user a notice that the item does not meet the purchase criteria and 
information relating to why the item did not meet the purchase criteria. 

4. The method of claim 3, further comprising the steps of: 

when at least one item in the set of items does not meet the purchase criteria, 
providing to the first user a representation of the set of items, receiving from the first user 
a proposed adjustment to the set of items, and providing to the first user notice of which 
items in the adjusted set of items would meet the purchase criteria and which items in the 
adjusted set of items would not meet the purchase criteria. 

5. The method of claim 3, further comprising the step of: for at least one item 
in the set of requested items that meets the purchase criteria: 

sending to a second user a request for approval of the item; and 

receiving from the second user a response to the request for approval of the item. 

6. The method of claim 3, further comprising the step of: for at least one item 
in the set of requested items that meets the purchase criteria, sending to the vendor of the 
item information permitting the purchase of the item. 

7. A method for conducting transactions over a network comprising the steps 

of: 

establishing one or more purchase criteria for a first user; 
selecting a pre-approval status for items meeting the purchase criteria; 
receiving from one or more vendors a set of items requested by the first user for 
purchase over a network; 

evaluating each item in the set of requested items against the purchase criteria; 

and 

for each item in the set of requested items that meets the purchase criteria, 
determining the pre-approval status of the item. 

8. The method of claim 7, further comprising the step of: for each item in the 
set of requested items that is determined to be pre-approved, sending to the vendor of the 
item information permitting the purchase of the item. 
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9. The method of claim 7, further comprising the step of: for at least one item 
in the set of requested items that meets the purchase criteria and is determined not to be 
pre-approved: requesting approval of the item. 

10. The method of claim 9, wherein the step of requesting approval of the item 
includes sending to a second user a request for approval of the item. 

11. The method of claim 9, further comprising the step of: for each item in the 
set of requested items that is determined to be pre-approved, sending to the vendor of the 
item information permitting the purchase of the item. 

12. The method of claim 7, further comprising the step of selecting a rejection 
notification status for items that are not approved. 

13. The method of claim 12, further comprising the step of: for each item that 
is not approved, if the selected rejection notification status includes providing 
notification, sending a notification to the first user for items that are not approved. 

14. The method of claim 13, wherein the step of sending a notification to the 
first user for items that are not approved includes providing to the first user a notice that 
the item does not meet the purchase criteria and information relating to why the item did 
not meet the purchase criteria. 

15. The method of claim 14, further comprising the steps of: 

when at least one item in the set of items does not meet the purchase criteria, 
providing to the first user a representation of the set of items, receiving from the first user 
a proposed adjustment to the set of items, and providing to the first user notice of which 
items in the adjusted set of items would meet the purchase criteria and which items in the 
adjusted set of items would not meet the purchase criteria, 

16. The method of claim 7, wherein the step of establishing purchase criteria 
includes establishing the purchase criteria with a plurality of sets of purchase criteria, 
each of the sets of purchase criteria being applicable to a different category of items. 

17. The method of claim 7, wherein the purchase criteria for the first user 
include criteria based on purchases made by other users. 

18. A system for permitting transactions over a network comprising: 

a server programmed to receive purchase criteria for a user and pre-approval 
status criteria for items meeting the purchase criteria, programmed to receive over the 
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network from a vendor a set of items requested by a user, programmed to evaluate each 
item in a set of items received from a vendor against the purchase criteria for the user, 
and programmed to determine, for each item in a set of requested items that meets the 
purchase criteria, a pre-approval status of the item from the pre-approval status criteria; 
and 

a database system coupled to the server, the database system programmed to 
maintain the received purchase criteria and pre-approval status, and to maintain for each 
item received from a vendor whether the item meets the applicable purchase criteria and 
whether the item has been approved. 
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Figure 9 
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